src/safe_outputs/set_issue_type.rs:20-23 — #[serde(untagged)] on GithubIssueNumber may mis-parse
GithubIssueNumber is #[serde(untagged)], so serde tries variants in declaration order. Number(u64) is listed first, and Temporary(GithubTemporaryId) second. A JSON string like "#aw_bug1" won't parse as u64, so it falls through correctly — but an integer-valued string like "42" will also fail u64 and fall through to GithubTemporaryId, which will then reject it with a confusing error about the #aw_ prefix rather than "expected a positive integer". More concretely: if the MCP layer ever serialises the number as a quoted string (some clients do), the error message will mislead the agent. Consider tagging the enum (e.g. #[serde(rename_all = "lowercase")] + an outer-object {type, value} shape) or explicitly testing that "42" (string) produces a clear error. This is a latent UX bug, not a security issue.

src/safe_outputs/create_issue.rs — duplicate-temporary_id check runs before resolve_target_repo
The has_resolved_github_issue guard fires before the target-repo is resolved. If resolve_target_repo would fail (e.g. non-GitHub pipeline with no configured target-repo), a second call with the same temporary_id returns "already used" rather than the config error. Not a security issue, but can confuse diagnostics — the guard and the repo resolution could swap order.

src/compile/common.rs — github_safe_outputs_auth() called twice at compile time
validate_github_issue_outputs_config (called in build_pipeline_context) ends with let _ = front_matter.github_safe_outputs_auth()?; to surface any auth-config errors early, and then build_safeoutputs_job calls it again. The duplication is harmless but it means the validation logic and the usage logic have to stay in sync. Extracting the auth result into BuiltPipelineContext (like executor_ado_env was) would make the data flow explicit and prevent future drift.

src/safe_outputs/set_issue_type.rs:369 — response.text() on non-success path uses .unwrap_or_else

.unwrap_or_else(|_| "<unable to read response body>".to_string())

This is fine as-is and consistent with create_issue.rs, just flagging it was reviewed and is intentional.

src/safe_outputs/create_issue.rs:311-318 — TOCTOU on temporary ID duplicate check
The pre-flight check calls has_resolved_github_issue (releases the lock), makes the HTTP call, then calls register_resolved_github_issue (re-acquires the lock). Two concurrent safe-output executors for the same run could both pass the pre-flight check and both file a GitHub issue. register_resolved_github_issue does have a second check inside the lock and bail!s, but that propagates as an anyhow::Error, not an ExecutionResult::failure — so it surfaces as a hard error rather than a graceful operator-facing failure message. Consider converting the inner bail! path to return ExecutionResult::failure at the call site in execute_impl, or document that the duplicate-registration case is intentionally a hard error.

src/safe_outputs/set_issue_type.rs — empty issue_type sends {"type": ""} to GitHub
The GitHub Issues REST API for clearing an issue type expects "type": null, not "type": "". Sending an empty string is likely to return a 422 Unprocessable Entity rather than clearing the type. The dry-run path and docstring both describe this as a "clear" operation, so the intent is correct — the payload should use serde_json::Value::Null when resolved_type is empty.

src/compile/common.rs:1501 — ADO_AW_GITHUB_API_URL written unquoted into generated YAML
generate_executor_ado_env emits ADO_AW_GITHUB_API_URL: {value} as a bare literal. The URL is validated at compile time via url::Url::parse (https-only), but a URL with a #fragment component — which url::Url permits — would produce malformed YAML. The parse_safe_outputs_github_api_url helper returns parsed.to_string() which preserves fragments. Reject or strip fragment components in that function, or quote the emitted value.

src/safe_outputs/set_issue_type.rs — no allowlist enforcement when allowed is empty
When the operator omits safe-outputs.set-issue-type.allowed, any agent-supplied issue_type passes through verbatim to GitHub (after reject_pipeline_injection). The analogous create-issue.allowed-labels works the same way, but issue types have no extra structural validation. Consider documenting this clearly in docs/safe-outputs.md so operators know an empty allowed list is fully permissive, not deny-all.

src/safe_outputs/result.rs:get_tool_config — silent require-approval removal
The new code strips require-approval from the config value before deserialisation to avoid deny_unknown_fields errors. This is correct, but a brief comment explaining the rationale would help future readers avoid confusion if a config struct ever legitimately needs this field.